home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Celestin Apprentice 5
/
Apprentice-Release5.iso
/
Source Code
/
C++
/
Applications
/
PICSee Dust 1.01
/
PICSee Dust.doc
< prev
next >
Wrap
Text File
|
1995-12-03
|
3KB
|
88 lines
PICSee Dust Notes:
Hiep Dam
12/3/95
For PICSee Dust version 1.01
Source code (whatever I wrote) is free.
The Viewer
===========
The Viewer supports the internal PICS information resource, 'INFO'. The only
parameter that the Viewer uses, however, is the speed parameter. All others
(depth, version, etc) are ignored.
By default, if the speed of the PICS file is changed, or if it never had
an 'INFO' resource to begin with, the Viewer will save the the speed to
the 'INFO' resource (or create one if none existed).
You can tell the Viewer not to save the speed by keeping the <shift> key
down while closing the PICS Viewer window.
Also, the Viewer retrieves from the preferences whether to change the
file's creator type. If the file is modified in the above cases and if
the preferences are set to change the creator types, the Viewer will
update the PICS file info so that it's creator type matches that of
PICSilicious.
The Compositor
==============
<updated later>
The PICS Splitter
=================
The splitter will save the PICS file as PICT files, with either the
PhotoShop or Color-It creator type or the user-defined type.
The PICS Merger
================
The merged PICS file will have the PICSilicious creator type (since
the original PICT file creator types - supposedly PhotoShop or
Color-It - do not really support the PICS file format).
Stuff I've have to tweak out that I'm not comfortable with
----------------------------------------------------------
1) Update events: I've had to write an AppEmergencyUpdate() routine to handle
update events which aren't handled.
Example: put up one dialog, dismiss it and immediately put up another dialog.
Notice the ugly white areas resulting from the old dismmissed dialog. These
areas won't get update events until after the second dialog is dismissed. Note
that this could happen even if you don't have a second dialog, but instead
perform some lengthy operation. The update event doesn't get called until
the next pass at WaitNextEvent - which doesn't happen until your lengthy
operation is done.
AppEmergencyUpdate() goes through all windows in the app and gives them
an update message. Nice fix, but windows in other processes won't get
updated. No fix for this, I think.
Read Apple TB37: Pending Update Perils (TB == newer Tech Notes) for
the lowdown...
2) AppendDITL: Using this causes an update event for the dialog (instead of
it just calling DrawDialog). If you have other items which are *erased*
and redrawn in response to update events, and they are not effected by
the change in DITLs, you'll get noticeable flicker. These items are
in effect getting spurious update messages - they don't need updating,
only the added DITLs do.
I've added a static global in one case, in which I set it if I've used
AppendDITL (and thus causing the update event). When my update routine
is called, it checks this global flag. If the flag isn't set, I know
that AppendDITL wasn't called and this is a bona-fide real update event.
Erase and redraw.
3) The select multiple files dialog in the Merge... menu command isn't
quite working as I would like. Also, it's not PowerPC-compatible
(it compiles fine with my modifications, but will crash at runtime).
However, since I didn't write it I'm not complaining. I will try to
fix the problems in the next release.